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Executive  Summary 


Background 


This  report  develops  an  enterprise-wide  architecture  for  the  use  of  information  systems  in 
support  of  the  MCI  activities.  The  overall  architecture  is  specified  by  defining  three 
types  of  architectures; 

1 .  Data  Architecture:  Defines  the  major  kinds  of  data  needed  to  support  MCI  business. 
IDEFIX  modeling  is  used  to  represent  data. 

2.  Functional  Architecture:  Defines  the  major  functions  of  the  enterprise  needed  to 
manage  the  data.  IDEFO  modeling  is  used  to  represent  this  architecture. 

3.  Technology  Architecture.  Defines  the  technology  platforms  needed  to  provide  an 
environment  for  the  applications  that  manage  the  data  and  support  business  functions. 

In  addition  to  defining  the  above  architectures,  a  set  of  matrices  is  developed  showing  the 
relationship  between  entities,  functions,  organization  units  and  locations.  The 
information  provided  by  these  matrices  is  intended  to  challenge  management  to  think 
about  its  structure,  mission,  goals,  and  the  information  needed  to  run  MCI  business. 

Subsequent  efforts  will  develop  detailed  data  and  process  models  for  the  Student  Services 
Functions  and  the  associated  design  specifications  for  development  of  information 
systems  applications  to  support  Student  Services. 


Conclusions 

1 .  The  development  of  an  enterprise  wide  model  and  detailed  data  and  process  business 
area  models  are  the  necessary  building  blocks  for  developing  any  information  system, 
without  which  the  success  of  a  project  is  doubtful. 

2.  A  detailed  process  analysis  of  a  business  area  provides  an  opportunity  for  the 
redesigning/reengineering  of  certain  processes  to  reduce  costs,  improve  efficiency,  and 
better  meet  the  needs  of  the  customers. 

3.  Client/server,  open  systems,  relational  technology,  and  graphical  user  interface 
technologies  are  the  direction  which  the  IT  industry  is  heading  and  should  form  the  basis 
of  selecting  any  future  target  platform. 
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4.  To  successfully  manage  risk  and  change  and  given  the  deep  roots  of  the  current  legacy 
system  and  infrastructure,  it  is  not  advisable  to  migrate  to  the  target  architecture  in  one 
step.  Rather,  a  phased  methodology  should  be  adopted  to  minimize  the  number  of 
variables  to  be  changed,  thus  increasing  the  probability  of  success. 


Recommendation 


1 .  Adopt  a  phased  approach  to  upgrade  the  current  technology  platform.  The  first  phase 
consists  of  upgrading  the  HP  3000  minicomputer  and  using  it  as  a  server,  installing  a  new 
Oracle  DBMS  under  the  current  MPE/ix  operating  system,  and  replacing  the  current 
dumb  terminals  with  client  pentium  level  microcomputers.  The  second  phase 
incrementally  migrates  to  a  true  open  system  architecture  and  consists  of  an  Intel-based 
server,  Windows  NT  operating  system,  Oracle  DBMS,  and  state-of-the-art 
microcomputer  clients. 

2.  Assemble  or  contract  for  a  high  caliber,  well-trained  programming/implementation 
team  proficient  in  the  development  environment  of  choice  and  provide  enough  overlap 
with  the  NPS  analysis  and  design  team  to  minimize  misinterpretation  of  requirements  and 
facilitate  a  smooth  transition. 

3.  Develop,  in  cooperation  with  NPS,  a  detailed  migration  plan  for  hardware,  software, 
data,  procedures,  and  personnel.  An  important  aspect  of  the  plan  is  user  training  for  the 
new  environment. 

4.  Establish  a  priority  and  schedule  for  developing,  refining,  and  reengineering  the 
business  area  process,  beyond  the  student  services  functions,  according  to  the  business 
areas  identified  in  this  study. 

5.  Examine  the  set  of  high  level  matrices  developed  in  this  study  that  show  the 
relationship  between  entities,  functions,  organization  units  and  locations.  Use  the 
information  obtained  from  the  matrices  to  review  the  mission,  functions,  goals, 
organization  structure,  and  the  information  needed  to  run  MCI  business. 
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I.  Introduction 


A.  Background 


The  Marine  Corps  Institute  was  established  to  “develop,  publish,  distribute,  and 
administer  distance  training  and  education  materials  to  enhance,  support,  or  develop 
required  skills  and  knowledge  of  Marines  and  to  satisfy  other  training  and  education 
requirements  as  identified  by  the  Commanding  General,  MCCDC.”  To  accomplish  its 
mission,  MCI  is  organized  into  seven  functional  departments:  education  &  operations, 
student  services,  occupation  specialty,  professional  military  education,  production,  and 
logistics  departments. 

The  student  services  department  mission  is  to  support  the  enrollment,  grading  and 
management  of  the  Marine  Corps  distance  education  and  training  programs.  In  support  of 
its  mission,  the  student  services  department  employs  an  automated  information  system 
(AIS)  to  automate  the  actions  required  to  support  a  student  in  the  MCI  correspondence 
program,  maintain  student  records,  and  produce  necessary  management  reports.  The 
automated  system,  known  as  the  Marine  Corps  Institute  Automated  Information  System 
(MCIAIS),  is  a  legacy  system  developed  in  the  late  1970's.  It  runs  on  a  Hewlett-Packard 
3000  mini  computer  running  MPE/iX  operating  system.  MCIAIS  is  written  in  HP 
proprietary  language  “Transact”  and  accesses  a  Turbo-IMAGE  hierarchical  database. 

As  typical  of  many  legacy  systems,  MCIAIS  suffers  fi-om  many  shortcomings; 

1 .  It  has  over  110  “spaghetti  coded”  programs  that  are  difficult  to  maintain,  modify, 
and  upgrade 

2.  It  does  not  have  an  underlying  data  or  process  models 

3.  Programs  have: 

.  Poor  functionality 

.  Poor  checks  and  balances 

•  No  statistical  analysis  capability 

.  Limited  “ad  hoc”  query  capability 

4.  It  utilizes  a  “closed”  non-relational  database 

5.  It  does  not  support  Graphical  User  Interfaces 

6.  It  does  not  follow  DoD  or  USMC  standards 

In  response  to  these  shortcomings,  MCI  initiated  a  project  to  redesign  and  rewrite 
MCIAIS  using  an  open  hardware  and  software  architecture.  In  addition  MCI  is  also 
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reviewing  and  redesigning  the  business  processes  to  better  support  its  mission  and  current 
advances  in  training  and  education. 


B.  Objectives 

The  objective  of  this  research  project  is  to  support  MCI  in  transforming  their  current 
legacy  information  system  into  a  modem  environment  that  can  take  advantage  of  “open” 
technologies.  Specifically  the  effort  will  1)  perform  a  detailed  analysis  of  data  and 
process  requirements,  2)  review  existing  SSD  processes  and  redesigning  them  to  increase 
efficiency  and  reduce  costs,  3)  develop  a  target  hardware  and  software  architecture  based 
on  open  systems,  4)  provide  assistance  in  the  implementation  of  the  new  system,  5) 
develop  a  migration  plan  from  existing  legacy  system  to  new  system. 


C.  Scope 

The  scope  of  this  report  is  the  development  of  an  enterprise-wide  data,  process,  and 
technology  architectures  for  the  use  of  information  in  support  of  the  MCI  activities. 
Subsequent  efforts  will  develop  detailed  data  and  process  models  for  the  Student  Services 
Functions  and  the  associated  design  specifications  for  the  development  of  information 
systems  applications  to  support  Student  Services. 


D.  Methodology 

The  approach  adopted  for  the  development  of  the  enterprise-wide  model  for  MCI  follows 
closely  the  Enterprise  Architecture  Planning  and  Information  Engineering 
Methodologies.  It  develops  the  overall  architecture  by  defining  three  kinds  of 
architectures: 

Data  Architecture:  Defines  the  major  kinds  of  data  needed  to  support  MCI  business. 
IDEFIX  modeling  is  used  to  represent  data. 

Process  Architecture:  Defines  the  major  kinds  of  processes  needed  to  manage  that  data 
and  support  the  business  functions.  IDEFO  modeling  is  used  to  represent  this 
architecture. 

Technology  Architecture.  Defines  the  technology  platforms  needed  to  provide  an 
environment  for  the  applications  that  manage  the  data  and  support  the  business  functions. 
In  addition  to  defining  the  above  architectures,  a  set  of  matrices  are  developed  that  show 
the  relationship  between  entities,  functions,  organization  units  and  locations.  The 
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information  provided  by  these  matrices  is  intended  to  challenge  management  to  think 
about  its  structure,  mission,  goals,  and  the  information  needed  to  run  MCI  business. 


E.  Organization  of  Report 

This  report  is  organized  as  follows: 

Chapter  II  presents  the  Enterprise  Business  Model.  This  includes  documenting  the 
organization  structure,  business  locations,  and  business  functions  and  the 
relationships  between  them. 

Chapter  III  presents  the  Enterprise  Data  Model.  This  includes  the  high  level  entities 
(subject  areas),  their  attributes,  and  the  relationships  between  the  entities.  The 
relationships  between  data  entities,  organization  units,  locations,  and  business 
functions  is  also  developed. 

Chapter  IV  determines  what  functions  create/read  which  entities  by  developing  a 
Create/Read  (CR)  business  fimctions  vs.  high  level  entities  matrix.  This  matrix  is 
then  clustered  to  reveal  the  major  information  subsystems  to  support  the  enterprise. 

Chapter  V  presents  the  enterprise  technology  platforms  and  proposes  three  options, 
with  associated  costs,  for  migrating  the  current  legacy  system  to  a  contemporary, 
client/server  open  system. 

Finally,  Chapter  VI  summarizes  the  report  and  presents  some  conclusions. 
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Enterprise  Business  Model 


This  chapter  creates  the  enterprise  business  model  for  MCI.  It  follows  the 
guidelines  of  the  enterprise  architecture  planning  methodology  outlined  by 
Steven  H.  Spewak  in  his  book,  Enterprise  Architecture  Planning  The  steps  of  the 
Spewak  methodology  for  creating  an  enterprise  business  model  are:  1)  document 
the  organization  structure,  and  2)  identify  and  define  the  business  functions.  The 
remainder  of  this  chapter  explains  the  steps  in  greater  detail. 


A.  Document  the  Organization  Structure 

This  step  documents  the  structure  of  the  organization  and  identifies  the  location  that 
perform  the  business  functions.  To  successfully  complete  this  step,  it  is  important  to 
identify  individuals  to  interview  and  determine  the  extent  of  data  and  application  system 
sharing.  Data  was  collected  in  several  ways.  Before  the  first  interview,  team  members 
studied  the  read-ahead  package  provided  by  MCI.  The  package  included  existing 
organizational  structure,  an  incomplete  business  model  that  had  been  done  previously  by 
an  independent  contractor,  a  collection  of  existing  data  dictionary  entries,  existing  data 
dictionaries,  task  breakdown  of  the  Student  Services  Department,  and  documentation  and 
background  information  about  the  Marine  Corps  Institute. 

1.  Identify  Business  Stake  Holders 

An  organization  chart  was  provided  by  MCI  along  with  a  telephone  directory  and  e-mail 
contact  information.  Department  chiefs  were  identified  and  introduced  at  the  initial 
planning  meeting  in  August  1996.  See  Exhibit  1,  Appendix  A  for  an  MCI  organizational 
chart. 


2.  Interview  Users  and  Developers 

Following  the  MCI  departmental  briefs,  team  members  interviewed  the  department  chiefs 
as  well  as  telephone  operators  from  the  student  services  department  and  computer 
programmers  in  the  information  systems  department.  After  the  in-brief  the  team 
conducted  additional  in-depth  interviews,  to  ask  additional  questions  and  gather  more 
information. 
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3.  Documentation,  Input  Screen,  Output  Report 
Review 

Additional  documentation,  training  manuals,  SOPs,  existing  input  screen  shots,  and 
management  reports  were  collected  to  enhance  the  information  gathered  during 
interviews  and  help  to  clarify  the  business  rules. 

4.  Identify  and  Define  Business  Locations  Where 
the  Functions  Take  Place 

A  tour  of  the  MCI  headquarters  in  August  revealed  the  location  of  the  MCI  offices  and 
work  spaces  where  the  various  business  activities  take  place.  Exhibit  3,  Appendix  A 
show  the  MCI  organizational  units,  locations,  and  relationship  between  them.. 


B.  Identify  and  Define  the  Business  Functions 

1.  Identification  and  Definition 

A  business  function  is  a  collection  of  any  set  of  actions  performed  in  the  course  of 
conducting  business.  Business  function  definitions  exist  to  understand  the  business 
process  as  a  whole.  They  are  the  very  essence  of  the  business  but  do  not  include  every 
detail  of  the  business  process.  Business  process  details  are  added  during  the  Business 
Area  Analysis  (BAA).  At  the  enterprise  level,  business  function  definitions  do  not  show 
who  performs  the  function,  how  the  function  is  performed,  where  the  function  is 
performed,  when  the  function  is  performed,  the  importance  or  priority  of  the  function,  the 
technology  or  resources  used  by  the  function,  or  the  flow  of  inputs  outputs  or  personal 
interactions  of  the  function.  The  MCI  enterprise  level  business  functions  are  defined  in 
Exhibit  2,  Appendix  A. 


2.  Relate  the  Business  Functions  to  the 
Organizational  Units  That  Perform  Them 

To  ensure  that  all  business  functions  were  included  in  the  analysis,  several  matrices  are 
generated.  These  include  the  organization  versus  location,  organization  versus  function, 
and  location  versus  function  matrices.  These  matrices  show  the  extent  to  which 
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departments  share  data  or  perform  redundant  functions.  These  matrices  are  included  as 
exhibits  in  Appendix  A. 


Matrix 

Exhibit  #,  Appendix  A  I 

Organization  vs.  Location 

Exhibit  3,  Appendix  A 

Organization  vs.  Function 

Exhibit  4,  Appendix  A 

[Location  vs.  Function 

Exhibit  5,  Appendix  A 

C.  Conclusion 

This  set  of  high  level  matrices  show  the  relationship  between  functions,  organization 
units  and  locations.  The  information  obtained  from  the  matrices  can  be  analyzed  to 
redefine  the  mission,  functions,  goals,  organization  structure,  and  the  information  needed 
to  run  MCI  business. 
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III.  Enterprise  Data  Model 


This  chapter  presents  the  enterprise  wide  data  model  for  the  Marine  Corps  Institute 
(MCI).  Section  A  describes  the  general  methodology  used  for  developing  the  conceptual 
data  model.  Section  B  describes  the  specific  enterprise  wide  model  designed  for  MCI.  It 
is  important  to  note  that  this  chapter  describes  the  enterprise  wide  MCI  model.  A 
subsequent  report  will  focus  on  the  data  model  designed  to  support  the  Student  Services 
Department  (SSD)  and  the  Management  Information  Systems  (MIS)  Department. 


A.  Methodology  for  Developing  the  Data 
Architecture 


This  section  presents  the  strategy  used  for  the  development  and  distribution  of  the  data 
architecture  in  a  client/server  environment.  The  methodology  used  for  developing  the 
data  architecture  is  a  four  step  process.  The  steps  of  the  process  are:  1)  list  candidate 
data  entities,  2)  define  the  entities  and  their  associated  attributes  and  relationships,  3) 
develop  the  data  model,  and  4)  relate  the  entities  to  the  business  functions.  The 
flowchart  of  Figure  3-1  illustrates  this  process. 

1.  List  Candidate  Data  Entities 

The  first  step  in  the  development  of  the  data  architecture  for  a  client-server  based 
information  system  is  to  list  the  candidate  data  entities.  This  process  begins  with  the 
study  of  the  existing  data  sources.  This  is  accomplished  by:  1)  collecting  information  by 
distributing  questionnaires,  interviewing  developers,  administrators,  and  end-users;  and 
2)  studying  existing  system  documentation,  screens,  and  reports. 

a.  Questionnaires  and  Interviews 


Analysis  begins  with  the  distribution  of  questionnaires  and  the  conduct  of  interviews  with 
developers,  programmers,  administrators,  and  users  of  the  current  database.  Interviews 
are  especially  useful.  Interviews  with  database  developers  and  administrators  focus  on 
the  structure,  functions,  and  modification  of  the  existing  database.  Interviews  with  users 
focus  on  the  applications  and  processes  which  access  the  data.  User  interviews  are  useful 
in  identifying  data  elements  used  in  manual  processes  that  should  be  modeled  in  order  to 
automate  these  processes.  Whenever  possible,  on-site  interviews  are  conducted.  They 
afford  the  opportunity  for  direct  analysis  of  data,  interviewing  the  largest  number  of  key 
participants,  and  allow  for  a  demonstration  of  the  existing  system.  Additionally,  copies 
of  all  available  documentation  are  on  hand.  Follow 
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up  communications  is  accomplished  by  scheduling  telephonic  conferences,  as  well  as  the 
exchange  of  electronic  mail. 


Refinement 


Figure  3-1 


b.  Documentation,  Input  Screens,  and  Output 
Report  Review 

Information  gathered  from  documentation,  user  input  screens,  and  output  reports 
augments  the  data  collected  from  the  developer  and  user  interviews.  All  available 
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information  on  existing  data  structures,  data  types  and  definitions,  database  interface  and 
download  procedures,  and  data  process  definitions  is  reviewed.  User  input  screens 
further  reveal  data  needs  as  well  as  the  structure  of  existing  data.  Data  dictionaries  are 
reviewed.  Information  stored,  accessed,  and  updated  manually  is  examined  in  detail,  and 
this  information  is  grouped  into  appropriate  entities  in  order  to  facilitate  the  automation 
of  manual  processing.  Review  of  existing  processes  is  done  in  conjunction  with  business 
process  re-engineering  team  members,  as  the  development  of  the  future  data  model 
supports  their  re-engineering  effort.  Output  reports  are  reviewed  with  end-users  to 
determine  their  usefulness  and  any  data  elements  contained  in  them  which  are  not 
considered  useful.  Additionally,  users  are  asked  to  identify  reports  not  currently  available 
which  would  be  desirable  in  the  future  system. 

c.  Develop  Candidate  Entity  List 

Based  on  the  collected  background  information,  a  candidate  entity  list  is  drafted.  This  list 
is  the  basis  of  the  enterprise  wide  data  model.  It  may  be  refined  during  subsequent 
development  stages. 


2.  Define  The  Entities  and  Their  Associated 
Attributes  and  Relationships 

Once  the  candidate  entities  are  listed,  they  must  he  clearly  defined.  Additionally, 
candidate  attributes  for  these  entities  are  developed  and  defined.  Many  of  the  candidate 
attributes  will  be  identified  during  the  analysis  of  the  existing  system.  Once  identified, 
the  attributes  must  be  defined.  Finally,  the  relationships  between  the  entities  must  be 
identified  and  defined. 

It  is  not  necessary  that  all  attributes  and  relationships  be  listed  and  defined  at  this  stage. 
Additional  attributes  and  relationships  will  reveal  themselves  throughout  the  development 
process.  At  a  minimum,  primary  keys  must  be  identified  during  this  stage.  Primary  keys 
are  explained  in  section  three  below. 

3.  Develop  the  Data  Model 

The  most  effective  means  of  communicating  the  structure  of  a  database  is  through  the  use 
of  a  conceptual  data  model.  There  are  several  commonly  used  modeling  techniques  that 
have  been  standardized  and  are  easily  understood.  For  this  project.  Integration  Definition 
for  Information  Modeling  (BDEFIX)  was  selected  as  the  modeling  technique.  IDEFIX 
has  been  standardized  by  the  National  Institute  of  Standards  and  Technology  (NIST)  as 
documented  in  the  Federal  Information  Processing  Standards  (FIPS)  Publication  184.  As 
such,  IDEFIX  is  the  standard  modeling  technique  for  use  by  the  federal  government. 
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including  the  Department  of  Defense.  The  following  section  presents  a  brief  overview  of 
the  E)EF1X  Model. 

a.  IDEF1X  Model 


The  IDEFIX  model  is  a  simple  modeling  technique  for  database  design.  Though  not  as 
common  as  the  Entity-Relationship  (E-R)  diagram  technique,  the  IDEFIX  technique  has 
the  advantage  of  being  standardized  by  NIST.  As  such,  it  provides  a  method  of  insuring 
that  the  design  of  the  conceptual  model  is  understood  by  all  involved  parties. 

Unless  otherwise  stated,  the  IDEFIX  modeling  features  used  in  this  project  are  in 
compliance  with  FIPS  PUB  184.  Background  and  history  on  the  IDEF  family  of 
modeling  techniques  is  available  in  that  publication. 

IDEFIX  was  developed  to  meet  the  following  requirements. 

1)  Support  the  development  of  conceptual  schemas.  The  IDEFIX  syntax  supports  the 
semantic  constructs  necessary  in  the  development  of  a  conceptual  schema.  A  fully 
developed  IDEFIX  model  has  the  desired  characteristics  of  being  consistent,  extensible, 
transformable,  and  expandable. 

2)  Be  a  coherent  language.  IDEFIX  has  simple,  clean,  consistent  structure  with  distinct 
semantic  concepts.  The  syntax  and  semantics  of  IDEFIX  are  easy  to  grasp,  yet  are  robust 
enough  to  satisfy  most  project  needs. 

3)  Be  teachable.  IDEFIX  is  easily  taught  to  users  and  customers  not  familiar  with 
semantic  data  modeling.  It  can  easily  be  understood  by  management  information  system 
professionals,  as  well  as  executive  level  supervisors,  end  users,  application  developers, 
and  other  project  team  members. 

4)  Be  well-tested  and  proven.  IDEF  IX  is  based  on  many  years  of  experience  with 
predecessor  techniques,  and  has  been  tested  in  numerous  Air  Force  development  projects, 
as  well  as  in  private  industry. 

5)  Be  automatable.  IDEFIX  diagrams  can  be  generated  automatically  by  many  CASE 
tools,  including  ERw/n®,  a  forth  generation  CASE  tool  marketed  by  Logic  Works®. 
Additionally,  ERww®  has  the  advantage  of  being  capable  of  generating  Structured  Query 
Language  (SQL)  based  conceptual  schemas  for  a  variety  of  target  databases  and  database 
servers.  These  schemas  can  include  a  variety  of  referential  integrity  triggers  and  indexes 
to  insure  both  data  integrity  and  performance  optimization. 

The  IDEFIX  model  consists  of  three  basic  constructs. 
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1)  Things  about  which  data  is  kept,  e.g.,  people,  places,  ideas,  events,  etc.,  as  represented 
by  a  box  (these  boxes  are  commonly  referred  to  as  entities). 

2)  Characteristics  of  those  things  as  represented  by  attribute  names  within  the  box. 
ERw/w®  provides  the  ability  to  also  represent,  for  each  attribute,  the  associated  data  type 
and  field  length  in  the  language  of  the  target  database.  Though  this  is  not  in  accordance 
with  FIP  PUB  184,  we  have  chosen  to  graphically  depict  the  associated  data  type  and 
field  length  for  each  attribute  in  our  model.  This  is  done  to  provide  clarity  to  the  model. 

3)  Relationships  between  those  things,  represented  by  lines  cormecting  the  boxes. 

Attributes  contain  detailed  information  about  entities.  Attributes  can  be  single  valued, 
such  as  the  course  number  for  a  particular  course,  or  multi-valued,  such  as  the  phone 
numbers  in  a  particular  office.  Additionally,  attributes  may  be  composite  (i.e.,  composed 
of  several  single  value  attributes)  such  as  the  composite  attribute  address,  which  is 
composed  of  house  or  apartment  number,  street,  city,  state,  and  zip  code  attributes. 

An  attribute,  or  combination  of  attributes,  must  exist  for  each  entity  which  will  uniquely 
identify  an  instance  of  that  entity.  This  attribute  (or  combination  of  attributes)  is  known 
as  the  entity's  primary  key.  If  the  primary  key  is  a  combination  of  attributes,  it  is  known 
as  a  composite  key.  If  other  unique  attributes  exist,  but  are  not  designated  as  the 
identifying  attribute,  they  are  known  as  alternate  keys. 

When  two  entities  are  related,  their  relationship  is  identified  through  the  use  of  these  key 
fields.  This  is  done  by  embedding  the  primary  key  of  one  entity  into  the  entity  to  which 
it  is  related.  For  example,  if  there  are  two  entities  STUDENT  and  RUC/MCC,  the 
relationship  is  clearly  described  as  a  RUC/MCC  has  many  STUDENTS,  but  a  STUDENT 
may  belong  to  one  and  only  one  RUC/MCC.  In  this  case  the  primary  key  firom 
RUC/MCC  (RUC/MCC_ID)  would  be  embedded  in  each  instance  of  STUDENT 
belonging  to  that  RUC/MCC.  These  embedded  keys  identify  which  students  belong  to  a 
particular  RUC/MCC.  They  are  known  as  foreign  keys. 

A  foreign  key  may  be  the  primary  key  (or  part  of  the  primary  key)  of  the  entity  in  which 
it  is  embedded.  If  that  is  the  case,  the  relationship  is  said  to  be  an  identifying 
relationship.  If,  however,  the  foreign  key  is  not  needed  to  uniquely  identify  the  entity  in 
which  it  is  embedded,  the  relationship  is  said  to  be  non-identifying.  In  the  example 
above,  a  STUDENT  is  uniquely  identified  by  his  social  security  number  (SSN  ID),  and 
does  not  depend  on  the  foreign  key  RUC/MCC_ID  for  his  identity.  This  relationship 
would  be  a  non-identifying  relationship. 

Relationships  define  the  associations  between  attributes.  Associations  are  characterized 
by  degree,  cardinality,  and  participation  constraints.  Degree  defines  the  number  of 
entities  involved  in  a  relationship.  Most  relationships  are  binary  in  nature  (the 
STUDENT_COURSE  example  in  Figure  3-2  is  binary  in  nature).  Some  relationships 
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may  be  of  greater  degree.  The  relationship  between  child  and  parent,  for  example,  is 
tertiary  in  nature.  A  child  has  two  parents. 


Above,  the  "many-to-many”  relationship  between  students  and  courses  is  depicted. 
This  is  a  binary  relationship,  as  it  involves  only  two  entities. 

Figure  3-2 


Cardinality  refers  to  the  number  of  instances  each  entity  involved  in  the  relationship. 
Minimum  cardinality  refers  to  the  minimum  number  of  instances  of  an  entity  that  may  be 
involved  in  a  relationship.  Maximum  cardinality  refers  to  the  maximum  number  of 
instances  of  an  entity  that  may  be  involved  in  a  relationship.  Using  the  student-course 
relationship  from  Figure  3-2  as  an  example,  zero,  one  or  many  students  may  take  zero, 
one,  or  many  courses.  In  this  example,  zero  is  the  minimum  cardinality  and  many  is  the 
maximum  cardinality  of  both  student  and  course.  Commonly,  minimum  cardinalities  are 
not  referred  to  when  describing  relationships.  Thus,  the  relationship  of  students  to 
courses  would  be  described  as  a  "many  -  to  -  many"  relationship. 

Participation  constraints  indicate  whether  the  existence  of  an  entity  depends  on  it  being 
related  to  another  entity  through  the  relationship  type.  In  IDEFIX,  entities  constrained 
by  participation  are  known  as  dependent  entities.  Their  existence  is  said  to  depend  on  the 
existence  of  another  entity.  In  IDEFIX,  entities  are  said  to  be  either  dependent  or 
independent.  Independent  entities  are  said  to  be  parents,  and  their  dependent  entities  are 
known  as  children.  Some  of  the  common  IDEFIX  modeling  symbols  are  diagrammed  in 
Figure  3-3.  A  complete  listing  of  these  symbols,  as  well  as  their  associated  definitions  is 
included  in  FIBS  PUB  184. 

Additionally,  some  relationships  involve  entities  which  share  common  characteristics. 
These  are  referred  to  as  generalization  or  inheritance  hierarchies.  They  are  also  referred 
to  as  sub-type  relationships.  For  example,  we  might  find  during  a  modeling  project  that 
several  different  types  of  PERSONNEL  exist  in  an  organization,  such  as 
COURSE  WRITERS,  CUSTOMER_SERVICE_REPS,  and  WAREHOUSEMEN.  A 
generalization  entity  called  PERSONNEL  is  formed  to  represent  information  common  to 
all  three  types  of  PERSONNEL.  The  relationship  would  be  expressed  as,  "a  person  may 
be  a  course  writer,  customer  service  representative,  warehouseman,  or  other." 

A  generalization  hierarchy  may  be  complete  or  incomplete.  For  example,  a 
generalization  entity  may  exist  called  PERSONNEL  with  two  sub-type  entities,  MALE 
and  FEMALE.  This  would  be  a  complete  structure,  as  all  personnel  must  be  either  male 
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INDEPENDENT  ENTITY  (box  with  square  comers) 

Primaiy  Key  (above  the  horizontal  line,  (PK)  notation) 

Non-key  attributes  (below  the  horizontal  line) 

Those  attributes  designated  as  inversion  entries  have  (lEn)  notation 

Foreign  Key  (non  identifying,  below  horizontal  line) 


DEPENDENT  ENTITY  (box  with  rounded  corners) 

Foreign  Key  part  of  Primary  Key  (identifying  relationship) 
Composite  Key  (composed  of  two  or  more  attributes) 

Non-key  attributes  (below  the  horizontal  hne) 


zero  or  one  -  to  -  zero  or  one  relationship 
zero  or  one  -  to  -  one  relationship 

zero  or  one  -  to  -  zero,  one  or  many  relationship 
zero  or  one  -  to  -  zero  or  one  relationship 
zero  or  one  -  to  -  one  or  many  relationship 

one  -  to  -  zero,  one  or  many  relationship 
one  -  to  -  zero  or  one  relationship 
one  -  to  -  one  or  many  relationship 
many  -  to  -  many  relationship 

Non-Identifying  Relationship  Identifying  Relationship 

Figure  3-3 
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SSN  Number  (PK) 
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or  female.  The  same  generalization  entity  may  contain  the  sub-type  entities 
CONSULTANT  and  CIVILIAN.  This  structure  would  be  incomplete,  as  their  may  be 
personnel  who  are  neither  consultants  or  civilians. 

Generalization  Hierarchies  may  be  appropriate  for  the  following  three  reasons. 

1)  The  entities  share  a  common  set  of  attributes. 

2)  The  entities  share  a  common  set  of  relationships. 

3)  The  categories  of  an  entity  should  be  exposed  (modeled  as 
sub-types)  if  the  business  demands  it,  even  if  the  categories  have  no 
attributes  that  are  different,  and  even  if  they  participate  in  no 
relationships  distinct  from  other  categories. 

The  symbols  associated  with  generalization  hierarchies  are  illustrated  in  Figure  3-4. 


PERSONNEL 


£ 


:i — [ 


MiLE" 


i 


fenIale 


CONSULTANT  CIVILIAN 


Complete  Sub-types 


Incomplete  Sub-types 


Figure  3-4 


b.  ERmn®  Issues 

Commonly  in  data  modeling,  entities  are  defined  as  items  of  interest  in  the  user's 
environment.  As  such,  they  are  usually  real  world  objects.  ERwn®  restricts  the 
modeler's  use  of  "many  -  to  -  many"  relationships  for  the  purpose  of  schema  generation. 
All  "many  -  to  many"  relationships  must  be  resolved  into  "one  -  to  -  many"  relationships 
in  order  to  generate  schemas  using  ERw/«®.  This  forces  the  model  to  depict  conceptual 
items,  which  are  not  real  world  objects,  as  entities. 

For  example,  a  student  can  enroll  in  many  courses,  and  a  course  can  have  many  students. 
Both  student  and  course  are  real  world  objects  and  as  such,  in  data  modeling  terms, 
would  be  known  as  entities.  Additionally,  they  are  entities  in  a  "many  -  to  -  many" 
relationship.  ERh'/w®  forces  the  modeler  to  resolve  this  relationship  into  two  "one  -  to  - 
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many"  relationships  by  creating  an  "association  entity"  between  student  and  course.  This 
entity  might  be  called  "STUDENT_COURSE_X".  As  a  result,  the  IDEFIX  diagram  as 
modeled  in  ERwz'n®  can  easily  become  cluttered  with  these  association  entities,  created 
for  the  sole  purpose  of  resolving  "many  -  to  -  many"  relationships.  This  is  graphically 
illustrated  in  Figure  3-5. 


Above,  the  "many-to-many"  relationship  between  students  and  courses  is  depicted. 


A  STUDENT  can  enroll  in  many  COURSES  A  COURSE  may  have  many  STUDENTS 

Figure  3-5 


Because  of  this  limitation,  it  is  useful  to  first  model  the  desired  system  without  regard  to 
this  somewhat  artificial  constraint,  thereby  allowing  for  the  existence  of  "many  -  to  - 
many"  relationships  on  the  diagram.  These  relationships  can  later  be  resolved  into  "one  - 
to  -  many"  relationships  for  the  purpose  of  schema  generation.  The  enterprise  wide  data 
model  depicted  in  section  B  of  this  chapter  has  unresolved  "many  -to  -  many" 
relationships. 

In  'Erwin®,  some  attributes  are  known  as  inversion  entry  attributes.  An  inversion  entry 
represents  an  additional  way  that  the  user  wants  to  access  data.  An  inversion  entry  is  an 
attribute  or  group  of  attributes  which  will  commonly  be  used  to  access  the  entity,  but 
which  may  not  result  in  the  finding  of  exactly  one  instance.  For  example,  consider  the 
entity  STUDENT.  It  may  be  identified  by  the  key  field.  Student  Social  Security  Number. 
However,  the  user  may  want  to  search  the  entity  for  a  student  whose  last  name  is  Smith. 
If  the  attribute  Last  Name  is  designated  as  an  inversion  entry,  an  index  will  be  built  on 
the  attribute  Last  Name,  and  the  user  will  be  able  to  rapidly  access  all  instances  of  the 
STUDENT  entity  with  the  Last  Name  of  Smith. 

Inversion  entry  notation  is  not  standardized  in  FIBS  PUB  184,  but  is  a  key  feature  in 
ERwm®.  When  inversion  entries  are  designated  in  an  ERw/w®  model,  they  cause  an  index 
to  be  built  on  those  designations  whenever  a  schema  is  generated  for  a  target  database. 
Because  of  this  utility,  they  are  used  to  designate  those  fields  which,  although  not  unique, 
are  most  likely  to  be  searched  during  database  queries. 
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c.  Ad  Hoc  Designed  Databases 


Ad  hoc  databases  are  those  databases  which  have  been  designed  and/or  implemented 
without  the  benefit  of  a  conceptual  data  model.  In  most,  but  not  all,  cases  these  databases 
are  non-relational.  Usually  they  consist  of  flat  file  data  files,  with  a  great  deal  of  data 
redundancy,  and  no  defined  relationships.  Data  manipulation,  retrieval,  and  association  is 
done  programatically,  and  is  not  based  on  the  data  definitions  or  meta-data  contained  in 
the  database.  Ad  hoc  query  language  such  as  SQL  cannot  be  used,  and  retrieval  of  data  is 
often  impossible. 

When  developing  a  conceptual  model  for  a  future  system  based  on  an  existing  ad  hoc 
database,  those  portions  of  the  ad  hoc  database  that  are  relevant  to  the  project  must  be 
re-engineered  in  a  top  down  fashion,  based  on  a  good  deal  of  investigative  work.  This 
investigative  work  consists  of  gathering  facts  about  the  data  and  its  representations 
through  a  study  of  the  database  structure  files,  input  forms,  output  reports,  interviews, 
user  screens,  and  all  other  available  documentation. 


d.  Formally  Designed  Databases 

Databases  which  have  been  formally  developed  using  a  conceptual  data  model  are 
considered  formally  designed  (Kamel  and  McCaffrey,  1995).  These  databases  are 
structured  relationally,  generally  are  developed  using  CASE  tools  such  as  ERw/w®,  and 
contain  detailed  data  dictionaries  and  design  documentation.  An  understanding  of  formal 
database  design  is  crucial  for  the  maintenance  of  the  future  system.  In  order  to  maintain 
the  future  database,  and  its  accompanying  data  model,  it  is  necessary  that  database 
maintenance  personnel  clearly  understand  the  principles  of  IDEE  IX  modeling,  as  well  as 
the  underlying  theory  of  relational  database  design. 


4.  Map  Entities  to  Functions  in  the  Process 
Model 

After  the  initial  identification  of  target  entities,  these  entities  are  mapped  to  functions  in 
the  business  process  model  which  have  been  identified  by  the  business  process 
re-engineering  team.  The  business  process  re-engineering  team  groups  functions  by 
related  entities.  As  these  functions  are  grouped  and  refined,  the  major  sub-systems 
emerge.  During  this  process,  entities  are  refined,  broken  into  sub-entities,  and  the 
normalization  of  the  data  model  is  accomplished.  No  entity  should  exist  that  is  not 
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created,  read,  updated,  deleted  or  archived  by  a  function  identified  during  the  business 
process  analysis.  Additionally,  all  automated  business  processes  must  be  supported  by 
the  underlying  database. 

a.  Map  Entities  to  Business  Functions 

In  this  step,  high  level  entities  are  clearly  defined  to  the  process  re-engineering  team. 
These  entities  are  mapped,  in  the  form  of  a  CRUD  matrix,  to  the  business  functions.  In 
the  CRUD  matrix,  a  "C"  designates  data  subjects  that  are  created  by  a  function,  an  "R" 
those  data  subjects  that  are  read  by  a  function,  a  "U"  those  data  subjects  that  are  updated 
by  a  function,  a  "D"  those  data  subjects  that  are  deleted  by  a  function,  and  an  "A"  those 
data  subjects  that  are  deleted  by  a  function. 

In  order  to  accomplish  this  mapping,  both  entities  and  functions  must  be  clearly  defined. 
High  level  entities  are  referred  to  as  data  subjects.  The  collection  of  data  subjects  should 
encompass  all  of  the  people,  places,  and  things  for  which  data  must  be  stored  in  the 
organization. 

Before  beginning  the  mapping  process,  it  is  useful  to  map  the  data  subjects  to 
organizational  units,  and  to  physical  locations  at  the  enterprise.  These  matrices  greatly 
assist  in  the  process  of  mapping  data  subjects  to  functions. 

b.  Refine  the  Conceptual  Data  Model 

Throughout  the  development  process,  the  conceptual  data  model  is  refined  and 
normalized.  Entities  are  broken  down  to  resolve  remaining  "many  -  to  -  many  " 
relationships,  and  normalization  is  achieved.  Normalization  is  the  process  of  breaking 
entities  into  two  or  more  sub-entities  to  ensure  that  all  the  attributes  in  the  entity  are 
related  to  the  primary  key,  the  whole  key  (in  the  case  of  composite  keys)  and  nothing  but 
the  key.  This  is  done  to  prevent  the  undesirable  consequence  of  modification  anomalies. 
A  deletion  anomaly  exists  when,  with  one  deletion,  facts  are  lost  about  two  logical 
entities.  An  insertion  anomaly  exists  when  data  cannot  be  inserted  into  a  logical  entity. 
Normalization  is  directed  at  removing  both  of  these  anomalies.  For  example,  suppose  we 
have  an  entity  in  our  database  as  depicted  in  Figure  3-6. 

STUDENT _ 

Student  ID  (PK) 

Activity  (PK) 

Activity  Fee 
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Information  pertaining  to  this  entity  would  appear  in  a  table  as  depicted  in  Figure  3-7. 


Stud  ID 

Activity 

Fee 

99 

Golf 

200 

10 

Scuba 

300 

33 

Tennis 

100 

36 

Golf 

200 

14 

Golf 

200 

Figure  3-7 


Now  suppose  that  Student  10  drops  out  of  school.  If  the  record  for  Student  10  is  deleted, 
then  we  lose  not  only  the  fact  that  Student  10  was  enrolled  in  scuba  diving  classes,  but 
also  the  fact  that  scuba  classes  cost  $300.  This  is  an  example  of  a  deletion  anomaly. 

Imagine  that  another  activity,  weightlifting,  is  offered  to  students  at  a  fee  of  $25.  That 
information  cannot  be  entered  into  the  database  until  a  student  enrolls  in  weightlifting. 

This  is  an  example  of  an  insertion  anomaly.  The  goal  of  normalization  is  to  remove  these 
anomalies. 

Normalization  is  defined  in  terms  of  normalization  forms.  Commonly  understood  forms 
are  first  through  fifth  normal  forms.  For  the  purposes  of  this  report,  it  is  sufficient  to 
describe  only  the  first  through  third  normal  forms. 

First  Normal  Form;  A  table  of  data  is  said  to  be  in  first  normal  form  if  it  meets  the 
definition  of  a  relation.  For  a  table  to  be  a  relation,  the  attributes  (cells)  in  the  table  must 
be  single  valued,  and  neither  repeating  groups  nor  arrays  are  allowed  as  values.  All 
entries  in  a  column  must  be  of  the  same  kind.  Each  column  must  be  uniquely  named. 
Finally,  no  two  rows  in  the  table  can  be  identical.  Inspection  reveals  that  the  table 
depicted  in  Figure  3-7  is  in  first  normal  form.  Thus,  first  normal  form  will  not  preclude 
modification  anomalies.  A  table  is  said  to  be  in  first  normal  form  if  every  attribute  is 
"about  the  key". 

Second  Normal  Form:  Examine  Figure  3-7.  Again,  the  primary  key  consists  of  both 
student  ID  and  activity.  The  problem  with  this  relation  that  activity  fee  is  dependent 
upon  only  part  of  the  composite  key.  The  fee  is  not  dependent  upon  the  student.  It  is 


Enterprise  Data  Model 


20 


dependent  only  upon  the  activity.  The  attribute  is  not  dependent  upon  the  whole  key.  A 
table  is  said  to  be  in  second  normal  form  if  every  attribute  is  "about  the  whole  key". 

Third  Normal  Form:  Consider  that  a  student  can  only  take  one  activity  and  an  activity 
can  only  have  one  fee.  Thus,  activity  is  dependent  upon  student,  and  fee  is  dependent 
upon  activity.  Put  another  way,  the  fee  is  determined  by  the  activity,  and  the  student's 
activity  is  determined  by  the  student's  ID.  Therefore,  it  can  be  said  that  indirectly,  the 
student's  ID  determines  the  fee.  This  arrangement  of  dependencies  is  formally  referred  to 
as  a  transitive  dependency.  Following  this  logic.  Figure  3-6  could  be  modified  such  that 
only  the  Student  ID  is  considered  to  be  the  primary  key.  This  is  illustrated  in  Figure  3-8. 

STUDENT _ 

Student  ID  (PK) 

Activity 
Activity  Fee 


Figure  3-8 

In  this  example.  Activity  Fee  is  dependent  upon  the  key,  so  first  normal  form  is  achieved. 
Activity  Fee  is  also  dependent  upon  the  whole  key  (this  should  be  obvious,  as  the  key  is 
not  a  composite  key).  Thus,  second  normal  form  is  also  achieved.  Yet  modification 
anomalies  can  still  exist.  This  is  due  to  the  transitive  nature  of  the  dependency  of  fee 
upon  student.  Removing  transitive  dependencies  will  yield  relationships  that  are  in  the 
third  normal  form.  A  table  is  said  to  be  in  third  normal  form  if  every  attribute  is  "about 
the  key,  the  whole  key,  and  nothing  but  the  key".  In  the  example  shown  in  Figure  3-8, 
third  normal  form  is  not  present,  as  fee  depends  not  only  on  the  primary  key,  but  also  on 
the  activity,  which  is  no  longer  part  of  the  primary  key. 


B.  Enterprise  Data  Model  for  MCI 

This  section  presents  the  application  of  the  strategy  described  in  section  A,  as  it  pertains 
to  the  MCI.  The  focus  of  this  project  is  the  development  of  a  data  architecture  to  support 
the  Student  Services  Department  (SSD)  and  Management  Information  Systems  (MIS) 
Department  at  MCI.  However,  to  facilitate  an  understanding  of  the  general  scope  of 
MCI's  future  information  system  needs,  the  data  model  section  of  this  report  focuses  on 
an  enterprise  wide  data  model  for  MCI.  The  database  design  section  of  a  subsequent 
report  will  focus  exclusively  on  the  SSD  and  MIS  departments. 
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1 .  List  Candidate  Data  Entities 


The  first  step  in  the  development  of  the  data  architecture  for  the  future  MCI  client/server 
based  information  system  v^as  to  study  the  existing  databases.  This  was  accomplished  by 
1)  interviewing  developers,  administrators,  and  end-users,  and  2)  stud5dng  existing 
system  documentation,  screens,  and  reports.  Normally,  questionnaires  would  be  used  to 
analyze  the  database  requirements  as  well.  A  data  collection  questionnaire  was  not  used 
in  this  project.  Questionnaires  were  not  used  because  of  the  limited  number  of  database 
administrators  and  end-users  and  their  ready  availability.  However,  areas  normally 
addressed  in  a  questionnaire  were  covered  through  a  series  of  interviews  and  site  visits. 

a.  Interviews 

Analysis  began  with  the  conduct  of  interviews  with  developers,  programmers, 
administrators,  and  users  of  the  current  database.  Interviews  with  Mr.  Joseph  Rudd  and 
Major  Donna  Gerlaugh  were  especially  valuable,  as  they  are  intimately  familiar  with  the 
structure,  functions,  nature,  modifications,  and  patches  associated  with  the  current  flat  file 
system  and  its  related  programs.  Interviews  with  the  users,  especially  in  SSD,  were 
useful  in  identifying  the  underlying  purposes  of  the  data,  as  well  as  their  associated 
processes  and  business  functions. 

Whenever  possible,  on-site  interviews  were  conducted.  On-site  interviews  (at  MCI) 
afford  the  opportunity  for  direct  analysis  of  data,  interviewing  the  largest  number  of  key 
participants,  and  allows  for  a  demonstration  of  the  existing  system.  Additionally,  copies 
of  all  available  documentation  are  on  hand.  Follow  up  communications  has  been 
accomplished  by  scheduling  telephonic  conferences  with  Mr.  Rudd  and  Major  Gerlaugh, 
as  well  as  through  the  exchange  of  electronic  mail. 

b.  Documentation,  Input  Screens,  and  Output 
Report  Review 

Information  gathered  fi’om  documentation,  user  input  screens,  and  output  reports  has  been 
used  to  augment  the  data  collected  form  the  developer  and  user  interviews.  In  the  case  of 
MCI,  the  existing  data  dictionary  is  incomplete,  poorly  documented,  and  not  current. 

Read  ahead  material  did  not  reflect  current  data  stores  and  data  definitions  in  many  cases. 
The  output  reports  provided  were  of  limited  use.  No  systematic  analysis  of  existing 
output  reports  was  conducted,  as  no  user  interviewed  placed  any  importance  on  the 
existing  reports.  The  common  theme  seemed  to  be  that  more  useful  reports  were  needed, 
based  on  statistical  analysis  not  currently  conducted. 
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c.  Develop  Candidate  Entity  List 

The  information  gathered  through  interviews  and  inspection  of  documentation  was  used 
to  develop  the  candidate  entity  list  for  the  enterprise  wide  MCI  data  model.  These 
entities,  at  the  enterprise  wide  level,  are  referred  to  in  this  report  as  data  subjects.  The 
candidate  entity  list  is  included  as  Exhibit  1,  Appendix  B. 


2.  Define  The  Data  Subjects  and  Their  Associated 
Attributes  and  Relationships 

From  the  list  of  candidate  data  subjects,  definitions  of  enterprise  wide  data  subjects  were 
developed.  These  definitions  are  shown  in  Exhibit  2,  Appendix  B.  Primary  keys  were 
identified,  as  shown  in  Exhibit  3,  Appendix  B.  Candidate  attributes  were  then  identified, 
as  illustrated  in  Exhibit  4,  Appendix  B.  These  attributes  were  then  defined  as  shown  in 
Exhibit  5,  Appendix  B.  Finally,  the  relationships  between  the  data  subjects  were 
identitfied  and  defined.  This  is  included  as  Exhibit  6,  Appendix  B. 

3.  Develop  an  Initial  Conceptual  Data  Model 

An  enterprise  wide  data  model,  containing  the  twenty-six  primary  subject  areas  and  their 
relationships,  was  developed  in  order  to  provide  a  better  conceptual  understanding  of  the 
architecture  needs  at  MCI  in  terms  of  development  costs,  and  future  hardware,  software, 
and  peopleware  needs.  This  enterprise  wide,  high  level  data  model  is  included  as  Exhibit 
7,  Appendix  B. 

The  detailed  SSD  model  and  accompanying  data  dictionary  has  been  provided  to  Major 
Gerlaugh  and  Mr.  Rudd  under  separate  cover,  at  the  time  of  this  report. 

The  reader  should  be  familiar  with  the  relational  database  design  concepts  introduced  in 
section  A  of  this  chapter  before  reading  the  proposed  data  model  for  MCI.  An 
understanding  of formal  database  design  is  crucial for  the  proper  maintenance  of 
MCI's  future  system.  In  order  to  maintain  the  future  database,  and  its  accompanying 
data  model,  it  is  necessary  that  MCI  personnel  clearly  understand  the  principles  of 
IDEFIX  modeling,  as  well  as  the  underlying  theory  of  relational  database  design. 

ERwm®  or  any  other  suitable  CASE  tool  should  be  used  to  facilitate  the  maintenance  of 
the  MCI  database.  The  conceptual  database  can  be  reverse  engineered  using  ERw/w®  . 
The  CASE  tool  reads  the  data  dictionary  from  the  specified  database  management  system 
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(DBMS)  or  target  DBMS  server,  and  uses  this  information  to  generate  an  IDEFIX  model 
and  accompanying  dictionary.  This  model  can  be  compared  programatically  by  the 
CASE  tool  with  the  file  containing  the  original  data  model.  This  allows  for  the  user  to 
verify  the  accuracy  of  the  current  database,  as  well  as  identify  changes  which  have 
occurred  since  initial  design.  Another  benefit  yielded  by  such  an  approach  is  the  ability 
to  rapidly  expand  and  contract  the  conceptual  data  model  and  accompanying  database  as 
user  requirements  change.  This  makes  the  data  model  a  living  document,  with  current 
documentation  throughout  its  life  cycle. 

Finally,  the  proposed  relational  data  model  for  MCI  requires  verification  from  the 
database  users  to  ensure  its  accuracy. 

4.  Map  Data  Subjects  to  Functions  in  the 
Process  Model 

The  enterprise  wide  data  model,  containing  the  twenty-six  primary  subject  areas  and  their 
relationships,  was  used  to  map  entities  to  functions  in  the  process  model.  As  previously 
mentioned,  these  entities  are  referred  to  as  data  subjects,  in  order  to  differentiate  between 
them  and  entities  of  the  same  name  contained  in  the  detailed  IDEFIX  model  developed 
for  SSD  and  MIS  at  MCI. 

a.  Map  Entities  to  Business  Functions 

After  the  initial  identification  of  these  data  subjects,  they  were  mapped  to  the  functions  in 
the  business  process  model  which  have  been  identified  by  the  business  process 
re-engineering  team.  This  mapping  was  diagrammed  in  the  form  of  a  CRUD  matrix. 

Before  beginning  this  mapping  process,  the  data  subjects  were  mapped  to  organizational 
units,  and  to  physical  locations  at  the  MCI.  These  matrices  assisted  in  the  process  of 
mapping  data  subjects  to  functions.  These  matrices  are  included  as  a  series  of  exhibits  at 
the  end  of  this  chapter. 


[Matrix 

Exhibit  #,  Appendix  B 

Data  Subjects  vs.  Organizational  Units 

Exhibit  8,  Appendix  B 

Data  Subjects  vs.  Physical  Locations 

Exhibit  9,  Appendix  B 

Data  Subjects  vs.  Functions  (CRUD  Matrix) 

Exhibit  10,  Appendix  B 

b.  Refine  the  Conceptual  Data  Model 

Once  the  initial  mapping  of  the  subject  areas  to  the  business  functions  was  complete,  the 
conceptual  data  model  was  refined  and  normalized.  This  process  was  only  conducted  for 
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those  data  subjects  directly  related  to  the  Student  Services  and  MIS  Departments,  as  all 
others  are  beyond  the  scope  of  this  project.  Entities  were  broken  down  to  resolve 
remaining  "many  -  to  -  many  "  relationships,  and  the  desired  degree  of  normalization  was 
achieved.  Some  degree  of  de-normalization  was  accepted.  For  example,  zip  codes  are 
not  included  on  a  separate  table.  As  previously  mentioned,  this  refined,  detailed 
conceptual  model,  with  its  accompanying  data  dictionary,  has  been  provided  to  MCI 
under  separate  cover  at  the  time  of  this  report. 
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IV.  Preliminary  Business  Model 


This  chapter  describes  the  methodology  for  the  development  of  the  clustered  Create  and 
Read  (CR)  Matrix  from  the  CRUD  matrix.  Clustering  the  CR  matrix  graphically 
illustrates  what  functions  and  data  subjects  fit  naturally  together,  thus  revealing  the 
major  organization  subsystems. 


A.  Develop  a  CR  Matrix 

The  CRUD  matrix  as  defined  in  chapter  III  maps  functions  against  data  subjects  (high 
level  entities)  arranged  in  life-cycle  order  (e.g.,  a  course  is  first  planned,  then  developed, 
managed,  and  finally  archived).  The  CRUD  matrix  can  be  further  refined  and  condensed 
into  a  "CR  matrix"  which  can  be  used  to  identify  organization  subsystems.  To  convert  a 
CRUD  matrix  to  a  CR  matrix,  identical  function  axis  and  data  subject  axis  are  used  on  a 
blank  matrix  but  all  "C" ,  "U",  "D",  and  "A"  entries  from  the  CRUD  diagram  are  depicted 
as  "C"  entries.  All  "R"  entries  from  the  CRUD  matrix  are  depicted  as  "R"  entries  on  the 
CR  matrix.  Exhibit  1,  Appendix  C  is  a  CR  matrix  made  from  the  CRUD  matrix  of 
chapter  III. 


B.  Cluster  to  Reveal  Organization  Subsystems 

Using  affinity  techniques,  the  "C"  intersections  are  "clustered."  Clustering  is  a  technique 
used  to  show  what  functions  and  data  subjects  fit  naturally  together.  Clustering 
rearranges  the  order  of  the  data  subjects  so  that  as  you  read  across  the  axis,  the  data 
subject  that  is  created,  updated,  deleted,  or  archived  by  the  first  function  (reading  down 
the  function  axis)  is  moved  to  the  left.  Then  the  data  subject  created,  updated,  deleted,  or 
archived  by  the  second  function  is  moved  to  the  left.  This  continues  for  all  data  subjects. 
The  resulting  matrix  has  all  the  "C's"  arranged  on  a  diagonal  line  running  from  the 
top-left  to  the  bottom-right.  The  data  subjects  can  now  be  "grouped"  into  subsystems  as 
shown  in  Exhibit  2,  Appendix  C. 

The  subsystems  can  now  be  given  names  that  relate  to  their  commonality.  Seven 
subsystems  were  identified  for  MCI:  Personnel  Administration,  Ceremonial  Support, 
Program  and  Course  Management,  Program  and  Course  Development,  Student  Service 
Support,  Warehouse  and  Distribution,  and  Information  Systems  management. 

When  data  use  falls  outside  of  any  box,  the  fijnctions  inside  the  box  must  access  the  data 
subject  elsewhere,  or  the  data  must  flow  from  one  subsystem  to  another.  At  this  point 
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business  activity  analysis  (BAA)  techniques  are  used  to  re-engineer  the  business 
processes. 


C.  Document  the  Preliminary  Business  Modei 

This  final  step  serves  as  the  final  validation  of  the  enterprise  model.  See  Exhibit  3, 
Appendix  C  for  the  Preliminary  Business  Model.  This  diagram  and  the  business  function 
definitions  (Exhibit  2,  Appendix  A)  serve  as  the  preliminary  business  model. 
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V.  Technology  Architecture 

This  chapter  discusses  the  principles  that  are  used  as  a  basis  for  formulating  technology 
architecture  at  MCI,  overviews  baseline  and  target  technology  platforms  and  proposes 
three  options  for  target  architectures  with  preliminary  cost  estimates  to  establish  financial 
planning  milestones  for  system  acquisition. 


A.  Principles  for  Technology  Architecture  at 
MCI 

The  following  principles  apply  to  the  formulation  of  a  technology  architecture  for 
the  Marine  Corps  Institute  project;  [Steven  Spewak,  Enterprise  Architecture 
Planning,  pg.  226],  These  principles  will  be  used  to  guide  the  formulation  of  the 
technology  architecture  options  in  section  C. 

1 .  Client/server  technology  will  be  used  for  applications  and 
database  implementation. 

2.  A  common  graphical  user  interface  will  be  used  by  all 
applications. 

3.  Data  storage  will  use  relational  technology,  and  data  access  will 
employ  SQL. 

4.  Apply  open  system  concepts,  meaning  operating  systems 
should  be: 

•portable  -  run  across  multiple  vendor 
platforms; 

•scalable  -  run  across  a  wide  power  range  from 
small  to  large  computers; 

•interoperable  -  run  in  a  heterogeneous 
environment;  and 

•compatible  -  preserve  the  investment  in  existing 
software  and  enable  technology  advances  to  be 
integrated  with  other  components. 

5.  System  development  methodology  should  employ  object 
oriented  techniques,  information  engineering  methods,  and  be 
supported  by  CASE  and  repository  tools  from  requirements 
analysis  through  code  generation. 

6.  Data  should  be  captured  once  at  its  source. 

7.  Data  should  be  administered  centrally  and  maintained  for 
shared  access. 

8.  Information  that  is  stored  online  will  be  continuously  available. 
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9.  Implement  distributed  data  and  application  systems  where 
possible. 

10.  Maintain  the  security  of  data,  software,  and  hardware  assets  at 
all  levels  of  the  technology  architecture,  with  security  being  as 
transparent  as  possible. 

11.  Ensure  recoverability  to  protect  the  continuation  of  business  by 
having 

•adequate  and  appropriate  backups  of  all  data; 

•software  with  built-in  error  checking  and  recovery 
capabilities;  and 

•integration  and  compatibility  of  hardware  with 
redundancies  for  critical  operations. 

12.  Adhere  to  established  Marine  Corps  standards  for  software. 

13.  Data  storage  must  be  compatible  with  World  Wide  Web  access 
requirements. 

These  principles  establish  the  fundamental  guidelines  which  will 
govern  the  development  of  the  technology  architecture.  By 
adhering  to  these  principles,  the  project  will  incorporate  a  design 
which  maximizes  industry  standards  and  trends,  ensures  the 
flexibility  of  the  system  for  current  use,  and  presents  the  best 
possible  alternatives  for  future  upgrade. 


B.  Baseline  and  Target  Technology  Platforms 


The  information  included  in  the  technology  platform  is  intended  to  summarize  the 
requirements  for  the  proposed  system.  It  incorporates  existing  hardware  and 
software  that  may  be  included  in  proposed  designs,  as  well  as  new  hardware  and 
software  that  will  be  required  to  support  proposed  designs.  The  additions  to  the 
technology  platform  are  in  keeping  with  the  technology  principles. 

1.  Baseline  Technology  Platforms 

The  baseline  technology  is  a  listing  of  the  platforms  currently  in  use  at  MCI  as  of 
February  1997.  It  does  not  include  planned  upgrades  or  additions  to  the  on-hand 
architecture. 

Hardware 
Minicomputers 
HP  3000  series  957SX 
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Microcomputers  (server) 

Application  servers  -  pentium 
Microcomputers  (client) 

Pentium  -  Windows  95  based 
486  -  Windows  3.11  based 
Input  Devices 

National  Computing  Systems  Scanner-OP7-35 

Mouse 

Keyboard 

Tape  drive 

Output  and  graphical  displays 
HP  laser  printer 
Xerox  4850  line  printer 
Storage  media 

CD  ROM  tower-6  unit  RO,  1  unit  Write  CD 

Software 
Operating  Systems 
Windows  95 
Windows  3.11 
DOS  6.22 
HP  MPE/ix,  ver  5.0 
DBMS 

HP  Turbo  Image 
Languages 
HP  Transact 
Powerhouse 
Quiz 
Qdesign 
QTP 
Other 

Lotus  Smart  Suite 

Biscom  Fax  Service 

Source  Library  System 

Plato  Courseware 

Shark!  Mail 

Fastran 

Edit  3000 

Facade 

Omnidex 
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2.  Target  Technology  Platforms 

The  target  technology  platform  list  represents  the  additional  technology  platforms  under 
consideration  in  support  of  the  options  contained  in  this  report. 

Hardware 

Minicomputers 

HP  3000  series  987,  987/150,  987/200 
Series  969/100,  969/200 
Microcomputers  (server) 

Enterprise  scale  server  -  Pentium  Pro,  200  MHz 
World  Wide  Web  server-Pentium  Pro,  166Mhz 
Microcomputers  (client) 

Pentium  -  Windows  95  based 
Pentium  -  Windows  NT  based 
Software 
Operating  Systems 
Windows  95 
Windows  NT 
HP  MPE/ix,  ver  5.5 
HP/UX 
DBMS 

Relational  DBMS  (Oracle  Server  7.3) 

Languages 

Oracle  Developer 
Other 

Communications 

Networks 
Operating  Systems 

Windows  NT  ver  4.0 


C.  Proposed  Architectures 

1 .  Overview 


The  three  options  contained  in  this  section  present  alternatives  for  technology 
architectures.  All  three  options  adhere,  in  varying  degrees,  to  the  principles 
established  in  section  A.  Regardless  of  the  option  chosen,  some  costs  will  be  the 
same,  others  will  vary  depending  on  the  option  chosen.  In  developing  these 
options,  the  guidance  from  MCI  to  build  in  seven  years  of  system  life  was 
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considered.  Training  and  migration  costs  are  not  yet  refined  to  reasonable 
estimates. 


2.  Option  One  -  HP  Minicomputer  Server 
Running  MPE/iX 

a.  Hardware/Software 

This  option  keeps  the  existing  minicomputer  server,  while  replacing  the  current 
database  system  and  application  with  a  relational  database  system  and  associated 
applications.  The  current  server  will  require  some  upgrade/replacement  of 
hardware  and  software  to  meet  growth  requirements.  The  957SX  can  be  upgraded 
in  incremental  steps  to  model  987/200  which  is  six  times  more  capable  than  the 
existing  minicomputer.  There  are  four  levels  of  upgrade  available  at  increasing 
increments  of  cost.  The  two  microcomputer  purchase  initiatives  currently 
underway  will  satisfy  client  workstation  requirements.  (See  Exhibit  1,  Appendix 
D) 


b.  Migration  Issues 

The  ability  to  use  the  existing  hardware  and  operating  system  (MPE/ix)  will 
enable  more  incremental  transition  for  the  MIS  personnel  at  MCI.  By  adding  the 
relational  database  to  existing  hardware  and  operating  system,  the  MIS  personnel 
will  be  able  to  focus  training  strategies  on  the  transition  to  a  new  database 
management  system,  without  simultaneously  having  to  learn  new  hardware  and 
operating  systems. 

The  input  data  (MCTFS)  for  the  new  database  is  currently  available  on  the  HP 
3000.  Since  the  current  server  and  operating  system  are  used  for  the  new 
environment,  the  proposed  action  will  allow  for  a  smoother  migration.  The  new 
database  will  be  installed  on  the  same  server  as  the  existing  one,  thus  greatly 
simplifying  the  migration.  Full  details  on  migration  issues  and  costs  are  currently 
being  developed. 
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c.  Development  Issues 


Development  costs  for  this  option  will  include  three  microcomputers,  application 
development  software,  support  for  this  software  and  compensation  for  the 
developers.  A  general  planning  figure  for  the  compensation  should  be  based  on 
six  developers  for  six  months.  Additionally,  training  for  MIS  personnel  in 
development  tools  and  DBMS  will  be  required. 

The  following  is  a  summary  of  the  pros  and  cons  of  this  option. 

Pros: 

1 .  Current  personnel  trained  on  HP  3000  hardware  and  MPE/ix 
operating  system 

2.  Support  system  already  in  place  for  HP  products 

3.  POSIX  compliant  operating  system 

4.  Potentially  simplified  migration 

Cons: 

1 .  MPE/ix  is  not  DoD  or  USMC  standard 

2.  MPE/ix  is  not  a  truly  open  system 

3 .  High  yearly  maintenance  costs 

4.  High  upgrade  costs 

3.  Option  Two  -  HP  Minicomputer  Server 
Running  UNIX  (HP/UX) 

a.  Hardware/Software 

This  option  requires  a  change  to  both  hardware  and  operating  systems.  The  HP 
3000  would  be  replaced  with  an  HP  969/200  as  the  base  hardware  for 
implementation,  and  the  operating  system  would  be  HP/UX,  which  is  the  HP 
version  of  the  UNIX  operating  system.  The  HP  969/200  is  the  next  generation  of 
HP  minicomputers  and  is  indexed  at  7  times  more  capable  than  the  current 
system. 

This  option  will  establish  a  relational  database  on  the  new  minicomputer, 
replacing  the  current  database  system  and  related  applications.  This  database 
server  will  be  capable  of  meeting  the  business  needs  of  the  SSD  for  the  required 
growth  cycle  (7  years).  The  two  microcomputer  purchase  initiatives  currently 
underway  will  satisfy  client  workstation  requirements.  (See  Exhibit  2,  Appendix 
D) 
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b.  Migration  issues 

This  option  is  more  complex  than  option  one,  but  less  complex  than  option  three. 

It  will  require  extensive  training  of  MIS  personnel  in  UNIX  and  is  likely  to 
increase  the  complexity  of  the  transition.  Entry  MIS  personnel  have  some  UNIX 
exposure,  and  UNIX  is  an  open  system  widely  used  in  industry  and  DoD.  In 
addition,  Oracle  support  and  experience  with  UNIX  platforms  is  the  most 
developed.  The  likelihood  of  simplified  interface  with  developing  technologies 
for  future  applications  and  equipment  is  improved  with  the  UNIX  0/S.  HP 
personnel  will  be  available  for  hardware  migration  assistance  to  facilitate  the  cut 
over  from  one  platform  to  the  other.  This  solution  has  greater  risk  than  option  one. 


c.  Development  Issues 

Development  costs  for  this  option  will  be  the  same  as  option  one  and  include 
three  microcomputers,  application  development  software,  support  for  this 
software  and  compensation  for  the  developers.  A  general  planning  figure  for  the 
compensation  should  be  based  on  six  developers  for  six  months.  Additionally, 
training  for  MIS  personnel  in  development  tools  and  DBMS  will  be  required. 

The  following  is  a  sununary  of  the  pros  and  cons  of  this  option. 

Pros: 

1 .  More  open  and  more  standard  operating  system 

2.  UNIX  0/S  is  preferred  platform  by  Oracle 

3.  UNIX  0/S  provides  better  World  Wide  Web  interface  and  design 

4.  UNIX  0/S  simplifies  external  services  (print  gateway) 

Cons: 

1 .  Significant  learning  curve  for  senior  MIS  personnel 

2.  Option  two  will  complicate  migration  by  requiring  new  hardware 
and  software  for  transition  period 

3.  UNIX  security  weaknesses 

4.  High  yearly  maintenance  costs 
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4.  Option  Three  -  Intel  Based  Server  Running 
NT 

a.  Hardware/Software 

This  option  establishes  a  relational  database  on  a  new  Intel  based  server,  capable 
of  meeting  the  current  and  future  business  needs  of  MCI.  It  includes  a 
replacement/upgrade  of  existing  workstations  with  new  equipment  (increased 
memory),  and  an  entire  0/S  migration  from  existing  software.  It  would 
standardize  the  0/S  for  the  database  server,  LAN  servers,  and  all  work  stations  to 
Windows  NT.  The  client  microcomputers  for  SSD  (and  any  other  users)  must  be 
32  bit  systems,  pentium  processors,  with  a  minimum  of  16  MB  memory  and  1  GB 
storage.  They  must  be  configured  for  network  access  and  provide  access  to 
electronic  mail,  business  suite  applications,  the  relational  database,  message 
system  software.  World  Wide  Web  access,  and  customer  service/help  desk 
applications.  (See  Exhibit  3,  Appendix  D) 

b.  Migration  Issues 

In  migrating  from  the  current  environment,  this  option  is  the  most  problematic.  It 
will  require  MIS  personnel  to  learn  a  new  0/S,  new  hardware,  new  applications, 
and  a  new  DBMS  simultaneously.  It  will  be  the  most  difficult  migration 
implementation  and  might  require  the  development  of  a  sophisticated  gateway  for 
transition  from  MPE/ix  Turbo  Image  to  a  Windows  NT  based  version  of  Oracle 
7.3. 

This  option  does  embrace  state-of-the-art  technology  and  will  place  MCI  in  the 
mainstream  of  technological  implementation.  There  is  significant  likelihood  that 
the  USMC  is  transitioning  to  NT  as  a  server  0/S,  and  this  would  position  MCI  to 
have  an  0/S  that  was  standard  compliant  and  enterprise  wide  (mail  server,  web 
server,  file  server,  database  server  all  on  the  same  0/S).  In  addition,  adopting  a 
single  0/S  across  client  and  server  would  simplify  middleware  issues  for  the 
system. 

c.  Development  Issues 

Development  costs  for  this  option  will  be  the  same  as  option  one  and  two  and 
include  three  microcomputers,  application  development  software,  support  for  this 
software  and  compensation  for  the  developers.  A  general  planning  figure  for  the 
compensation  should  be  based  on  six  developers  for  six  months.  Additionally, 
training  for  MIS  personnel  in  development  tools  and  DBMS  will  be  required. 
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The  following  is  a  summary  of  the  pros  and  cons  of  this  option. 

Pros: 

1.  Oracle  corporate  interest  in  NT  developments 

2.  Position  for  standardized  operating  systems 

3 .  Current  direction  of  industry 

4.  Newest  technology 

5.  Hardware  costs  are  comparatively  low 

Cons: 

1 .  Very  steep  learning  curve  for  MIS  personnel 

2.  Significantly  more  complicated  migration 

3 .  Client/server  middleware  reliability  issues 

4.  Many  more  variables-highest  risk 

5.  Recommendations 


A  major  guideline  in  recommending  an  option  for  implementation  is  its  likelihood 
of  success/risk  of  failure.  While  option  three  represents  state-of-the-art 
architecture,  and  is  therefore  the  best  for  long  term  success,  the  feasibility  of 
adopting  and  implementing  it  immediately  is  in  question  due  to  the  high  cost  of 
training  and  migration. 

It  is  therefore  recommended  that  MCI  adopt  a  phased  approach  to  upgrade  the  current 
technology  platform.  The  first  phase  is  option  one,  and  it  consists  of  upgrading  the 
current  HP  3000  minicomputer  and  using  it  as  a  server,  installing  a  new  Oracle  DBMS 
under  the  current  MPE/iX  operating  system,  and  replacing  the  current  dumb  terminals 
with  client  pentium  level  microcomputers.  The  second  phase  (option  three) 
incrementally  migrates  to  a  true  open  system  architecture  and  consists  of  an  Intel-based 
server,  Windows  NT  operating  system,  Oracle  DBMS,  and  state-of-the-art 
microcomputer  clients. 
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VI.  Conclusion 


This  chapter  summarizes  the  findings  of  this  preliminary  report. 


1 .  The  enterprise  level  business  functions  require  very  little  reorganization.  Several 
business  functions  were  identified  that  could  benefit  from  automation. 

2.  The  data  modeling  methodology  outlined  in  this  report  was  validated  and  revealed 
that  a  relational  database  could  be  developed  to  support  the  MCI  student  services 
department  function. 

3.  The  relational  database  will  allow  information  to  be  shared  between  student  services 
department  functions,  facilitate  automation,  eliminate  data  redundancy,  and  improve 
customer  service. 

4.  Three  technology  architecture  options  were  identified.  These  are  available  for  the 
implementation  of  the  client/server  open  architecture  system  and  underlying  relational 
database. 

5.  All  three  architectures  (business/process,  data  and  technology)  are  extremely 
important  for  successful  redesign  at  both  enterprise  and  business  application  area  levels. 


6.  The  enterprise  wide  model  revealed  eight  subsystems  in  the  clustered  CR  diagram. 

7.  Enterprise  wide  re-engineering  at  MCI  requires  the  level  of  analysis  that  the  student 
services  department  will  receive  during  the  remainder  of  this  project. 

8.  A  single  relational  database  can  be  developed  to  support  all  eight  subsystems. 

9.  With  regard  to  the  student  services  division  redesign  project,  migration  planning  will 
be  a  challenging  endeavor,  worthy  of  further  investigation.  In  order  for  a  successful 
migration  to  occur,  the  implementation  team  must  be  well  trained  in  the  chosen  tools 
and  allowed  to  interface  with  the  redesign  team  from  the  Naval  Postgraduate  School. 


Conclusion 


39 


Appendix  A. 

Enterprise  Business  Model  Exhibits 


Appendix  A.  Enterprise  Business  Model  Exhibits 


Appendix  B. 

Enterprise  Data  Model  Exhibits 


Appendix  B.  Enterprise  Data  Model  Exhibits 


Appendix  C. 

Preliminary  Business  Model  Exhibits 


Appendix  C.  Preliminary  Business  Model  Exhibits 


Appendix  D. 

Technology  Architecture  Exhibits 


Appendix  D.  Technology  Architecture  Exhibits 


MCI  Organizational  Chart 


Enterprise  Business  Model 
Exhibit  1,  Appendix  A 


Business  Function  Definitions 


0)  < 

0=5 
S  c 

«  ® 
(/)  Q- 
0)  CL 

.E  < 

3 

ffl  .ti: 

o  £ 
tn  £ 

'C  X 
aiu 

c 

LU 


Business  Function  Definitions 


©  < 

"S  X 
o  := 

S  c 

(0  s 

0)  Q. 

<D  O. 

.E  < 

3 

GQ 

0)  £ 
0)  £ 
■c  X 

aiu 


S 


lU 


Business  Function  Definitions 


Enterprise  Business  Model 
Exhibit  2,  Appendix  A 


Organizational  Unit  vs  Location 
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Candidate  Data  Subject  Report 
Lists  Candidate  Data  Subjects 
02/25/97  8:47  PM 

Maj.  Slaughter _ 

Data  Subject  Name 

ADVERTISMENT 
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COPY_MATERIAL 
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MCTF_PERS 

ORDER 

PROGRAM 
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Data  Subject  Definition  Report 
Lists  Data  Subjects  and  Their  Definitions 
02/25/97  8:53  PM 
Maj.  Slaughter 


Data  Subject  Name 

Data  Subject  Definition 

ADVERTISMENT 

Contains  information  on  advertising  projects.  Advertising  projects  are  related 
to  courses  and  programs 

COMPONENTS 

Table  of  all  items  stocked  by  MCI.  This  includes  items  included  in  courses  and 
programs(lessons,  course  material,  dictionaries,  etc.)  as  well  as  items  included 
in  job-aids  (FAC  manuals,  etc.) 

COPY_MATERIAL 

Copy  Material  is  any  text  or  graphic  material  which  must  be  written  or 
produced  by  a  developer  or  writer.  It  is  stored  electronically  as  binary  data  for 
future  reproduction  or  distribution  as  either  digital  or  paper  material.  It 
includes  such  things  as  exams,  course  material,  program  books  and  material, 
etc.  Due  to  the  size  of  some  material,  it  may  be  stored  on  some  backup  storage 
media.  If  this  is  the  case,  this  record  will  only  contain  a  pointer  to  indicate  the 
location  of  the  material.  Smaller  material  may  be  stored  directly  in  the 
database. 

COURSE 

All  active,  closed,  and  future  courses  as  entered  by  the  course  developer. 

COURSE_COPY_MATERIAL 

copy  material  which  is  associated  with  a  course 

COURSE_DEVELOPERS 

MCI  Course  developers  and  writers 

CUSTOMER 

Anyone  who  contacts  MCI  with  a  question.  Contact  may  be  by  telephone,  e- 
mail,  in  person,  regular  mail,  etc. 

EVENTS 

Parade  and  VIP  events  staffed  or  supported  by  MCI 

EXAM 

An  instance  of  a  specific  exam  as  generated  for  a  specific  course 

FINANCIAL 

Contains  budgeting  information.  Certain  line  items  may  be  associated  with  the 
funding  designated  for  the  development  of  courses  and  programs 

INVENTORY 

An  inventory  record  for  a  component 

IS_EQUIPMENT_INVENTORY 

Contains  the  inventory  records  of  all  IS  Equipment 

ISSUE_COMPLAINT 

A  customer  generates  an  issue  or  a  complaint 

JOB_AID 

Table  of  all  job  aids  stocked  by  MCI. 

JOB_AID_COPY_MATERIAL 

Copy  material  which  is  associated  with  a  job  aid 

MCI_PERSONNEL 

All  personnel  employeed  at  MCI 

MCTF_PERS 

Table  of  all  MCTF  personnel  as  downloaded  from  the  Total  Force  database 

ORDER 

An  order  is  any  request  by  a  customer  for  components,  job  aids,  courses,  or 
programs  other  than  an  actual  enrollment  in  a  course  or  program 

PROGRAM 

All  active,  closed,  and  future  programs  as  entered  by  the  program  developer. 

PROGRAM_COPY_MATERIAL 

Copy  material  which  is  associated  with  a  program 

PROGRAM_DEVELOPERS 

MCI  Program  developers  and  Writers 

PURCHASE 

All  course  components  are  purchased.  An  order  is  placed  by  a  MCI  clerk  and 
filled  by  a  supplier. 

SSD_PERSONNEL 

Personnel  working  in  the  Student  Services  Department 

STUDENT 

All  Students  contained  in  the  MCI  database 

TRAINING 

Training  programs  for  MCI  course  writers  and  programmers  are  described  here. 

WAREHOUSE 

A  warehouse  is  not  just  the  main  warehouse  or  warehouses  belonging  to 
logistics.  As  any  department  may  potentially  store  material,  there  may  be  one 
or  more  warehouses  associated  with  each  department 
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Base  Name  | 

Addrl 

Addr2 

BldgNumber 

BudgetAmount 

City 

Comments 

CommercialNo 

Component 

ComponentDescription 

ComponentName 

ComponentID 

CopyMaterial 

CourseAbbreviation 

CourseNumber 

CourselD 

CreditHours 

Custodian 

CustomerSSNJD 

DCTB 

DSNNumber 

Date 

DateClosed 

DateOpened 

Department 

Description 

DesignedFor 

ECC 

ECC 

EDD 

EventCoordinator 

EventDate 

EventDesc 

EventLocation 

EventName 

EventTime 

Event_ID 

ExamID 

FirstName 

Grade 

InvoiceNumber 

IssueNumber 

JobAidDescription 

JobAidName 

JobAidJD 

JobDescription 

LastName 

Lineltem 

Location 
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Base  Name 

MCTFSSNJD 

MOS 

Manager 

MateriallD 

Middlelnitial 

Nomenclature 

NumberOfQuestions 

OccFieldSpec 

OnHand 

OrdStatDate 

OrderDate 

OrderlD 

PDD 

PassingScore 

Phone 

PlatoonCode 

Pointer 

ProgramAbbreviation 

ProgramID 

ProjectJD 

Quantity 

RDD 

Rank 

ReserveCredits 

SSNJD 

SalesRep 

SchoolCode 

Section 

SelToGrade 

SerialNo 

State 

StudyHours 

Supplier 

Title 

TrainingProgID 

WarehouselD 

Year 

ZipCode 
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\  Organizational  Unit 

Data  Subject  \ 

Headquarters  | 

Training  &  Operations  Department  | 

Professionai  Military  Education  Department  | 

Occupational  Specialty  Department  | 

Student  Services  Department  | 

Management  Information  Systems  Departmei  | 

Logistics  Department  | 

Unit  Training  Representative  | 

Adv^ei^merit  " 

4'“?' 

Components  Information 

* 

* 

A 

Cow  MMeriat^^flftMTfiafioiB^n^  -  >  u" 

; 

•£  W'^sa»- 

L.'4 

Course  Information 

* 

* 

* 

A 

A 

Cour^'Copy  - 

'>  s:^ 

4:^ 

'j*'4 

vCf, 

4h^ 

Course  Developers  Information 

* 

* 

Cu^iiwr 

/Vr  ^  W 

lir- 

.'■-J-t 

\  -  >S\ 

=- 

■Wi  ‘-S^w 

Events  Information 

* 

A 

* 

* 

A 

* 

A 

Beam  Intonnabon 

f'jft’-V 

’1^ 

Financial  Information 

A 

* 

^l^ventofy^7n/&m^a^ton■v^-^-^«^f^viv;i■v 

v.My, 

4  'j 

IS  Equipment  Inventory  Information 

* 

IsOw'HBomplaii^lofcOTsftMrii^^ 

fVl  I.yi| 

Job  Aid  Information 

* 

* 

A 

A 

abWCdiJfMitW 

'■hfe 

MCI  Personnel  Information 

* 

* 

Mdl'Fls^rsdrtoei®^^ 

'■-.4-'  r^v 

'‘4-.k4 

r* 

SS 

$9 

Order  Information 

A 

* 

A 

' 

‘ 

hS  ' 

Program  Copy  Materiai  Information 

* 

I^TOQmmM^aktpejsInfi^  < 

^;Vvf 

-  il-i 

>.^r? 

Purchase  Information 

* 

A 

s|i^ 

^IS 

V’ 

Student  Information 

* 

* 

A 

A 

Tr^nlrig  inftmmmSin^ 

"''V* 

Warehouse  Information 

* 

_ 

A 

Updated:  17  Feb  1997 


Enterprise  Data  Model 
Exhibits,  Appendix  B 


Data  Subject  vs  Location 
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Cost  Worksheet  Option  One 
HP  Minicomputer  Server  Running  MPE/iX 
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Cost  Worksheet  Option  Two 
HP  Minicomputer  Server  Running  UNiX  (HP/UX) 
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Cost  Worksheet  Option  3 
Intel  Based  Server  Running  NT 
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Cost  Worksheet  Option  3 
Intel  Based  Server  Running  NT 
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